-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CloudWatch EMF Route RequestLifecycleHooks #105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I'm jumping into a naming debate here, but I'd like us to avoid using "middleware" for this, specifically because Flask and Werkzeug already have a type of object they support called a "middleware".
In their case, it's something which wraps a whole app, e.g.
app = app_factory()
app = CORSMiddleware(app, cors_config)
So I'm trying to find an alternative name which means basically the same thing.
"Lifecycle Hooks" or something like that?
Observer? (Not quite right, the hooks can modify data...)
HookCollection?
I'm struggling for a good name, but want to avoid an already-taken framework term.
Yeah I didn't expect that I'd get this one through undebated 😬. My reasoning for sticking with Middleware was that while flask does reference the term middleware, their "support" for it isn't really support. It's "hey wrap our app with a class that can do stuff and make sure it calls the app as well; we'll conventionally call that thing Middleware!" (ref) I believe the interface I've exposed (a class that taps into their builtin
|
@@ -67,7 +67,7 @@ class Config: | |||
) | |||
|
|||
|
|||
def test_action_enumeration( | |||
def mock_action_enumeration_func( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed these functions because they were named with test_
which caused pytest to think they were tests to be run when in fact they are utility callables for other tests to supply to the action provider blueprint as action provider view functions.
Example failure: https://github.com/globus/action-provider-tools/actions/runs/6510610219/job/17684687247?pr=105
Agree with all of the above—"middleware" feels like the clearest, but the potential for confusion is high in this context. I like |
I ran this PR by Stephen Zimmerman & he had the same comment about Updating in new rev |
I agree with you, but I think the potential for confusion is real enough (e.g. me in 6 months) that we should use a slightly less optimal name because the best name was (rudely!) taken from us. I'm on the I'll circle back to do a real content-ful review later, but I think it's all good from a quick scan. |
cough cough flows-logging cough cough |
assert emf_log.get("2XXs") == expected_2xxs | ||
assert emf_log.get("4XXs") == expected_4xxs | ||
assert emf_log.get("5XXs") == expected_5xxs | ||
assert type(emf_log.get("RequestLatency")) == float |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason on py3.12 windows (exclusively) this request latency comes back as 0.0 (my initial condition was request_latency > 0).
I don't know why that was the case (maybe it's inheriting freeze_time from other tests) but felt comfortable loosening the test to just verify that this is a number rather than a specific number/number range.
Example failure: https://github.com/globus/action-provider-tools/actions/runs/6510955778/job/17685743540
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still reviewing, but I have a comment that might be relevant to this, so I will push that before finishing review.
globus_action_provider_tools/flask/middleware/cloudwatch_metrics.py
Outdated
Show resolved
Hide resolved
assert emf_log.get("2XXs") == expected_2xxs | ||
assert emf_log.get("4XXs") == expected_4xxs | ||
assert emf_log.get("5XXs") == expected_5xxs | ||
assert type(emf_log.get("RequestLatency")) == float |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still reviewing, but I have a comment that might be relevant to this, so I will push that before finishing review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Approving now as I don't have any substantive concerns, but have a couple minor notes for consideration.
globus_action_provider_tools/flask/request_lifecycle_hooks/cloudwatch_metrics.py
Outdated
Show resolved
Hide resolved
…udwatch_metrics.py Co-authored-by: Ada <[email protected]>
for more information, see https://pre-commit.ci
What?
Added support for RequestLifecycleHook registration to the flask ActionProviderBlueprint class.
Classes may be provided at Blueprint instantiation time to register before, after, or
teardown functionality to wrap all view invocation.
Added a CloudWatchEMFLogger RequestLifecycleHook class.
When attached to an ActionProviderBlueprint, it will emit request count, latency, and
response category (2xxs, 4xxs, 5xxs) count metrics through CloudWatch EMF. Metrics
are emitted both at the aggregate AP and at the individual route level.
Dimension Sets
<action-provider-name>
}<action-provider-name>
, Route:<route-type>
}<route-type>
in this case is provided by the library not the user view func, so it'll be "run", "release", "resume", etc.Metrics:
Why?
Provide an easy mechanism for Action Providers to get usage metrics for both their aggregate Action Provider & specific routes of action providers
Usage
Testing
unit tested